This one I'm less sure about, since convex polygons tend to have a small number of vertices, and you can have a lot of them (ex: as a result of convex decomposition). I imagine that ConvexPolygon would primarily be used for collision detection or other geometry stuff where this can be relevant.

I wonder if the ideal representation would be to have a MAX_VERTICES const generic and to store an ArrayVec, that way you can store the vertices inline and have a cap based on how many vertices you expect to have 🤔 For example, for colliders I'd expect a max of 8 vertices per polygon. Box2D does basically the same (source).

Aside: Depending on what we intend ConvexPolygon to be used for, we might also want to store the outward edge normals here. It's required for collision detection, computing support faces, and some other stuff. For example Parry and Box2D store them. That's out of scope for this PR though.

My main concern is to be able to make these runtime constructible, which if they use non-defaultable const-generics becomes a problem. For my use case, I'd prefer to have a bit more flexibility but I'm happy to subordinate that if there are real performance concerns. Just adding a const default with a Vec constructor would be sufficient for me as it would allow constructing fewer than the default.

This should definitely be a Vec. if a physics engine needs a faster primitive it should implement it itself, bevy_math should be first and foremost Usable and Ergonomic

If we want a faster version with fixed vertices we can add them again as Ngon<N: usize>.

Should these just take a Vec, considering from_iter already exists if you want to use an iterator-like?

Personally I would "never" (say never) use Vec as an argument if I can have impl. Maybe remove from_iter instead?

If we change it, please add a comment to refer to from_iter.

from_iter here comes from the FromIterator trait, which makes sense to have implemented IMO.

I'm not sure if Rust does some special optimization here, but mainly my motivation is that from_iter does iter.into_iter().collect(), which (I believe) allocates a new vector, unless Rust is smart enough to figure out when it can just use the original vec. For most of my use cases I would instead want to move the given vector directly without doing any unnecessary allocations.

But you can also just not use the constructor at all and do Polyline2d { vertices: todo!() }, so it's not a big problem regardless

I think this should re-use the allocation in almost all instances but would have to double check under real use.
Briefly looking through the issue tracker rust-lang/rust#110353 suggests that this optimization is enabled for situations beyond the likely simple case here of passing a vec in directly.